Skip to content
QtWS25 Last Chance
  • 0 Votes
    5 Posts
    1k Views
    @J-Hilk Thanks! Hope it can be fixed soon. @jsulm Same thanks!
  • 0 Votes
    3 Posts
    1k Views
    Export watcher: int main(int argc, char *argv[]) { QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QGuiApplication app(argc, argv); QQmlApplicationEngine engine; const QUrl url(QStringLiteral("qrc:/main.qml")); QObject::connect(&engine, &QQmlApplicationEngine::objectCreated, &app, [url](QObject *obj, const QUrl &objUrl) { if (!obj && url == objUrl) QCoreApplication::exit(-1); }, Qt::QueuedConnection); QFileSystemWatcher watcher; watcher.addPath("data.json"); readJSON myGlobal; engine.rootContext()->setContextProperty("myGlobalObject", &myGlobal); engine.rootContext()->setContextProperty("watcher", &watcher); engine.load(url); return app.exec(); } and use Connections: Window { visible: true width: 800 height: 800 title: qsTr("Screen Display") DisplaysForm { function callCPP(text) { var dataOne = myGlobalObject.readingJson(text) dataOne = parseFloat(dataOne) return dataOne } function updateDisplay() { var value = callCPP("Engine_Spd") engSpd_txt.text = value var value1 = callCPP("Engine_Power") engPwr_txt.text = value1 } Connections{ target: watcher function onFileChanged(path){ console.log(path) updateDisplay() } } }
  • 0 Votes
    4 Posts
    3k Views
    @Core2 You are welcome :) it takes some time to get used to design/program with signals and slots. It can be a bit of a challenge to have pointers to both objects in same place but often the mainwindow is a good place. Note that its also ok to connect signal to signal. This can be used to surface some signals from inside a class to outside world. Like if you have a dialog with an TextEdit. The textEdit is private so outside cannot connect directly to it. You can then connect signal to a new public signal and the outside world can connect to this new signal. ( like TextReady) The good thing about this is that if you one day change the TextEdit to a combobox, the rest of the program do not need to change. It will still get the data via the new public signal TextReady. In a non trivial program, such encapsulation/hiding of details is worth every penny.
  • 0 Votes
    4 Posts
    7k Views
    difference between exec() and show(), Only QDialog have exec() Qwidgets have show. When you call show on a Dialog, it becomes visible but do not wait for input. example mainw::func() { MyDialog *dia=new MyDialog(this); dia->show(); int a=0; // this code is run the moment dialog is shown on screen, } using exec() mainw::func() { MyDialog dia; dia.exec(); int a=0; // this code is run only after dialog is dismissed. } The version of dialog where u call show() could be called floating so when user click ok it should emit signal that something should happen. ( to maiwindow ) The exec() version will report back the result ok/cancel/closed at once. learn when to use QObject, QWidget, QFrame QWidget is often used if making own widget. QFrame is used if you just need something to draw a frame. If you use Designer you can check out the Widgets that are available. QDialog is useful for any type of windows that pop ups up or open via a menu. I have to set anything inside Register. Yes, Register should be able to give the data back. the widgets inside are private so you need a function to return the data. You might also need to call http://doc.qt.io/qt-5/qdialog.html#accept in your Register buttons clicked slot.
  • 0 Votes
    4 Posts
    2k Views
    @namit ok super.
  • 0 Votes
    5 Posts
    2k Views
    @qtacc32 If you're still struggling with this if possible try sharing a real piece of the code. It might be something trivial that doesn't show up in the example (which looks fine). Or at least a MWE that reproduces the problem, since I could not run your example, since it's not complete. Kind regards.